Definfinity names a macro, with lambda list (NAME (LAMBDA-LIST USER-VAR PLANE-VAR) &BODY BODY):
Define an Infinity-mode “c” command NAME.
And now, let's talk about the Infinity Mode protocol.
In the Beginning, Tootsville used a commercial program called SmartFox Server as its chat server. There were many problems with this, and it didn't last long.
However, the client program (Persephone) was written to use the SmartFox client libraries, which were very good. So, we kept them, and used an AGPL chat server program created by Bruce-Robert Pocock, named Braque, to replace the server side. Braque was renamed Appius Claudius Cæcus, because SmartFox Server was from Italy, and Appius built the Via Appia, a highway leaving Italy.
Appius gained friends, all of which were given the names of other Romans, and so the entire software suite was nicknamed Romance, like Romans.
In order to negotiate a connection between Appius and SmartFox client, we had to provide a version identifier, so we set the version number to “infinity.”
With the adoption of the gossipnet for Romance II, we had to increment the version from infinity, which brings us to ℵ0 (read: Alef-Null), which is a particular kind of infinity that is not as big as some other kinds of infinity, as silly as that mathematical construction may sound (yes, that's real maths).
There are two main wire protocols; RESTful POSTs and gossipnet.
The REST POST interface is what you're really here to read about (on the server side). A POST is submitted with a JSON object representing a command call.
This request can be submitted to either the dedicated endpoint, or the general, dispatching endpoint. The dedicated endpoint will be slightly faster.
The dedicated endpoint will have a URL of the form /world/infinity/command-name, with the command name in lower-case and hyphenated.
The dispatching endpoint is /world/infinity. Submitting to the dispatching endpoint requires a JSON object with two keys:
In the case of the dedicated endpoint, only the contents of d need to be submitted.
There are three datagram kinds used in Infinity Mode.
The login process should be documented at TOOTSVILLE WEBSOCKET-AUTHENTICATE for WebSockets, TOOTSVILLE TCP-STREAM-AUTHENTICATE for direct TCP/IP server-to-server streams, and Tootsville.Gossip.createConnection for peer-to-peer WebRTC connections.
Command datagrams may be processed through either a REST POST or the Gossipnet. These represent an action or enquiry that a client is making.
Command datagrams are identified by a c key, which provides the command name in lowerFirstCamelCase. This command name is mapped to a function named INFINITY-COMMAND-NAME in hyphenated form.
Command datagrams usually have a d key which provides some additional data or parameters to the requested command.
In addition, there may be some of the following. Note that UUID's are the UUID's of a Toot character, never the person who “owns” that Toot.
Recipient. This can be an UUID for a direct peer-to-peer command, or is more often just $World for the game server or $All for all listeners.
Author. The UUID of the originator of the packet.
User. The UUID of the user who requested this packet; usually the same as a/Author.
Signature. Proof that the packet originated with a/Author.
Via. The history trail of a forwarded packet.
WRITEME
Gatekeeper datagrams are found either as the response to a REST POST, or distributed along the Gossipnet. These represent the state of the world at a certain point in time.
Every Gatekeeper datagram contains the keys from and status. The from value uniquely identifies the type of packet and determines what other fields accompany it. The status value is a Boolean, and while its meaning varies by packet, it is usually a good guess that if status is not true, there has been some kind of request error and data is not available.
For a complete enumeration
Defined in file src/infinity/infinity.lisp.